Date: Thu, 30 Jun 94 04:30:07 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #134 To: tcp-group-digest TCP-Group Digest Thu, 30 Jun 94 Volume 94 : Issue 134 Today's Topics: How about a new NOS KIT? Non-TCP/IP Related Radio for Sale NOS and the PC (3 msgs) Why not a solid PBBS program? (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 29 Jun 1994 16:12:55 -0400 (EDT) From: DJ Gregor Subject: How about a new NOS KIT? To: tcp-group@UCSD.EDU In the July '94 "Packet Perspective" in QST, Stan Horzepa, the column's author, mentioned that he distributed a plug 'n' play Macintosh TCP/IP package, and asked if there is such a package for MS-DOS. I have seen Dave Fritsche's (wb8zxu) nos_kit package, but it is over four years old. Is there a newer NOS KIT package? If not, let's get together and make one, and make it available. ----- DJ Gregor, N8QLB dgregor@bronze.coil.com ------------------------------ Date: Wed, 29 Jun 94 13:36:31 CDT From: route66@ddl.chi.il.us (System Administrator) Subject: Non-TCP/IP Related Radio for Sale To: tcp-group@ucsd.edu I have 3 800 mHz Trunked HT's for sale. They have MDC/CTCSS/DTMF Keypad/100 memoriesetc. They are the Uniden 800FPTS...1 for $100, or 3 for $250..all include rapid chargers/batteries. E-mail at system@ddl.chi.il.us for more info Also, TCP/I Related! I'm lookin for a good base/mobile rig to use on TCP/IP to setup a Conference @ Chicago. However, I lack a rig for this use. My Icom 22S which I was originally going to use died on me. If anyne has a radio they're willing to let me borrow/they wanna donate/sell (for extremly cheep!) E-mail me at system@ddl.chi.il.us Farewell, N9TOL - Greg Kaiser ------------------------------ Date: Wed, 29 Jun 1994 13:14:22 +0100 From: Adrian Godwin Subject: NOS and the PC To: tcp-group@ucsd.edu > Not being an expert I can only relate what I have heard and that is > that DMA, although it sounds great does not always give the results > you would expect. Many of the cards perform better, on fast processors, > in polled mode. > All the PC ethernet cards I know of do DMA from the ethernet controller to on-board memory. The differences appear when you transfer the ethernet packet from the card's memory to the PC's memory (and in the other direction). This can be done in one of 3 ways : Memory transfer : The ethernet card's mempory is visible in the PC's expansion space. A loop of code copies each byte (or word, on a 16-bit card) from the expansion area to main memory. Speed is limited by the I/O bus cycle time, and the processor's time to execute the loop. The WD8003 cards do this. e.g. while(length--) *memory++ = *card_buffer++; Programmed I/O : This is what's been described as polled, though I tend to reserve that term for systems where the CPU has to wait for a byte to be ready before copying. In fact, it's very similar to a memory transfer (and runs at similar speed). The difference is that the read from the card is performed at a single I/O location, and the transfer position within card memory is maintained by logic on the card. This saves expansion bus memory space. The NE1000 cards do this. e.g. while(length--) *memory++ = input(data_port); DMA : The PC's DMA controller is used to perform the transfer. The DMA controller performs a sequence of memory writes (using internal counters), but simultaneously drives signals to the card which act rather like an I/O read and provide a single byte in each operation. This halves the number of bus cycles used for the transfer, and requires no overhead from the CPU. However, the PC's DMA controller runs at 4MHz, so the actual transfer takes a lot longer (albeit at reduced system load) than if the CPU were to do the job, especially if the PC has an I/O system that can run at faster than the specified 8MHz. Also, DMA on the PC is a scarce resource, and may not run in 16 bit mode (not sure about that one). The NE1000 cards can do this, but the Crynwr packet driver uses programmed I/O. Disclaimer : I don't much like PCs, and have avoided becoming an expert on them. I might have made some or all of the above up, but I believe it until someone corrects me. -adrian ------------------------------ Date: Wed, 29 Jun 94 02:42:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: NOS and the PC To: tcp-group@UCSD.EDU Cc: crompton@nadc.nadc.navy.mil Cc: ssampson@sabea-oc.af.mil DC> You keep using the term "serial I/O" - actually it is parallel I/O DC> 8 or 16 bits from the ethernet card to the processor buss. The term DC> Polled I/O vs DMA can be applied to this connected Parallel I/O port. DC> In other words how is the data retrieved - direct to memory or handled DC> by the processor in a polled fashion. There are generally two architectures for Ethernet cards. The NE2000 style pulls an IRQ to signal that it has a buffer of data, usually a frame, but up to 16 or 32 KB. This is very efficient, especially from protected mode, because the processor can loop on I/O instructions rapidly, while it does very few context switches forced by the IRQ signal; as a result, this is ofter called "polled I/O" although that is not strictly true. This is contrasted with the usual serial port architecture where there is an IRQ pull and the resulting full context switch on each received byte. The other major design for an Ethernet card is the memory mapped style, where the 16 or 32 KB buffer appears in the processor address space. The card will still usually pull an IRQ line to signal that it needs attention, but the data will then be moved from the card to main memory using very fast memory-to-memory instructions. The disadvantage to this is that some very fancy footwork is required to do this kind of thing on a 386 or better processor in protected mode. DC> Not being an expert I can only relate what I have heard and that is DC> that DMA, although it sounds great does not always give the results DC> you would expect. Many of the cards perform better, on fast processors, DC> in polled mode. DMA is not particularly useful for Ethernet cards. It tends to be slower than the other methods when the motherboard DMA controller is used, and it requires extensive management and set up by the drivers. DMA in protected mode is a truly hellish thing. -- Mike ------------------------------ Date: Wed, 29 Jun 94 18:22:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: NOS and the PC To: tcp-group@UCSD.EDU Cc: agodwin@acorn.co.uk In a msg on , Adrian Godwin writes: AG> All the PC ethernet cards I know of do DMA from the ethernet AG> controller to on-board memory. Yes, but even we techno-dweebs in this group have limits to what we will actually worry about. The main issue is how the Ethernet card as a whole interfaces to the machine bus. AG> However, the PC's DMA controller runs at AG> 4MHz, so the actual transfer takes a lot longer (albeit at AG> reduced system load) than if the CPU were to do the job, AG> especially if the PC has an I/O system that can run at AG> faster than the specified 8MHz. The worst problem with DMA in the modern 386 world is that the machine address space can be mapped into physical memory such that the translation changes from time to time. In some cases, such as with Unix or OS/2, memory pages may actually be not present, which has very bad effects on DMA. AG> Also, DMA on the PC is a AG> scarce resource, and may not run in 16 bit mode (not sure AG> about that one). No, in a 286 or better, DMA channels 0-3 are 8-bit and 4-7 are 16-bit. Some of these are used for dedicated purposes, however. DMA channels are a scarce resource, somewhat like IRQs. -- Mike ------------------------------ Date: Wed, 29 Jun 94 10:29:00 EDT From: "Battles, Brian" Subject: Why not a solid PBBS program? To: TCP-Group DJ Gregor, N8QLB (dgregor@bronze.coil.com) said: > I've been thinking of something like this. If everyone could get together and write a > good Amateur Radio PBBS program for Linux-- **NOT** a JNOS port or something > like that, one that operates like a UNIX shell--we could then strip down the Linux > kernel, and integrate everything. Make it easy to configure and use--for the > *AVERAGE* PBBS operator, like the ones that run MSYS now. If we do that, we'd have > a NICE and POWERFUL PBBS that would run on an 80386 with 4 megabytes of memory. > Most MSYS operators I've seen have that kind of system already. Yeah, I have a similar question. I'm not a programmer, so I apologize for not being able to offer to do much to assist with such a project, but why isn't there a good, solid, NOS-based PBBS package available for hams who run DOS, Windows or OS/2 machines? Jeez, there's so much "old-style" (non-NOS) software out there (eg, W0RLI, WA4RE, MSYS, FBBS, etc), but so many people who want the considerable advantages of TCP/IP have such a hard time (A) Finding a version/compile that *works*, and (B) Struggling to get it configured so that it's compatible with the larger "world" of the AX.25 PBBS network. I know it can be done because a few people are doing it now, but a complete, stable "friendly" NOS PBBS package might be what it takes to get some SysOps into TCP/IP and off MSYS, W0RLI, FBBS, etc. As it stands, it sure seems much easier to set up an MSYS PBBS, and adding TCP/IP compatibility (SMTP, etc) is awfully tricky (I always hear NOS people saying that MSYS's SMTP stuff is "broken," etc). Perhaps it would take a commercial venture to do it right. Would a PBBS SysOp, who's spent maybe $1000-$2000 (or more) on radios, TNCs, antennas, PCs, etc, also shell out maybe $50-$100 or so for GOOD software that beats the heck out of the standard freebie AX.25 PBBS packages or the bazillion semi-complete NOSs floating around? Not to push for a greed-driven motive for working on better software solutions in Amateur Radio, but sometimes money can bring qualified people with their best efforts out of the woodwork! Something to think about... CUL es 73 de BB ___________________________________________________________________________ Brian Battles, WS1O I Internet bbattles@arrl.org I "Radio amateurs QST Features Editor I Compu$erve 70007,3373 I do it with high ARRL HQ I MCI Mail 215-5052 I frequency" Newington, CT USA I Tel 203-666-1541 I Amprnet ws1o@ws1o-2.ampr.org [44.88.2.43] Fax 203-665-7531 I AX.25 packet WS1O @ W1EDH.CT.USA.NA BBS 203-666-0578 I =--> Sometimes you have to look reality in the eye and deny it. <--= ___________________________________________________________________________ COMMENTS EXPRESSED HEREIN ARE MY OWN PRIVATE, PERSONAL REMARKS AND ARE TOO INANE TO BE CONSIDERED OFFICIAL ARRL VIEWS OR POLICY. ------------------------------ Date: Wed, 29 Jun 94 23:07 EDT From: glg@balrog.k8lt.ampr.org (Gary L. Grebus) Subject: Why not a solid PBBS program? To: tcp-group@ucsd.edu >but why >isn't there a good, solid, NOS-based PBBS package available for hams who run >DOS, Windows or OS/2 machines? Jeez, there's so much "old-style" (non-NOS) >software out there (eg, W0RLI, WA4RE, MSYS, FBBS, etc), but so many people >who want the considerable advantages of TCP/IP have such a hard time (A) >Finding a version/compile that *works*, and (B) Struggling to get it >configured so that it's compatible with the larger "world" of the AX.25 PBBS >network. I have some suspicions, but first let me ask a question. What are the "considerable advantages of TCP/IP" in the context of a PBBS? If the idea is to have users interacting with the standard PBBS interface, then I suggest that adding TCP/IP has considerable disadvantages. Use one of the fine PBBS packages mentioned above. If the idea is just to move data between the PBBS network and the AMPRnet, then that argues for minimal functionality. Or even better, run a PBBS and and NOS and interchange the data by filtering one set of files into another. As to why people have a tough time making NOS be a good PBBS and a good TCP/IP server: -- Either task alone is enough to fill the 640K DOS limit. (The expansion of PBBS function in NOS has come at the expense of TCP/IP features.) -- Gatewaying between the internet mail/news world and the PBBS world is a hard problem. Supporting both environments is much more than twice as hard. -- TCP/IP and PBBS's use AX.25 in different ways. Accomodating both adds complexity. If people are really set on evolving NOS, then what is needed is some *management* of the effort. Put the source code under a revision control system, and make controlled checkins possible on the Internet. Recruit a cadre of beta-testers whose use cover most of functionality (protocols, hardware, servers, compilers, etc) and application (PBBS, router, TCP server). Since customization is by re-compiling, automate test builds of various combinations of features and compiler versions. Mandate documentation checkins along with new functionality. Etc. The technology exists to do large, distributed software projects. But an ad-hoc approach is going to produce ad-hoc results, and the long term value of NOS is going to diminish. And with any luck, I'll be able to compile out all the stuff I don't need, get the latest and greatest of what I do need, and have it all be stable. 73, /gary K8LT Gary L. Grebus Home: glg@k8lt.ampr.org (decvax!balrog!glg) Brookline, NH Work: grebus@bxb.dec.com Ham Packet: K8LT@WA1PHY.#EMA.MA.USA "Stamp out the PBBS in our lifetime." ------------------------------ End of TCP-Group Digest V94 #134 ******************************